做出一個 RAG Demo，其實已經不算困難。

準備文件、切 chunk、做 embedding、丟進 vector database，再把 Top-K context 塞給 LLM，通常很快就能得到一個「看起來會回答」的系統。

真正困難的是下一句：

它到底有沒有變好？

如果我把 embedding model 換大、加入 BM25、加上 hybrid search、再接 reranker，最後回答變得比較像樣，這算進步嗎？

還是其實只是 Demo 剛好抽到一題比較容易的問題？

如果沒有固定 Query Set、沒有 relevance label、沒有 qrels、沒有 baseline，也沒有一致的 evaluation pipeline，那我們很容易陷入一種錯覺：

每加一個元件，系統看起來都更厲害。

所以這個系列的第一個原則很簡單：

先建立評測，再談 RAG 優化。

RAG 的問題，通常在 LLM 看到 Context 之前就發生了

RAG 可以粗略拆成兩個階段：

Retrieval
   ↓
Context
   ↓
Generation

很多文章把注意力放在最後一段：Prompt 怎麼寫、模型選哪個、Temperature 怎麼調。

但如果 Retrieval 一開始就沒有把正確文件找進 Top-K，後面的 LLM 再強，也只能在錯誤或不足的 context 裡回答。

這也是為什麼我會先把整個系列拆成七層：

1. Corpus / 文件
2. Query 設計
3. Human Label / Qrels
4. Retrieval Baseline
5. Rerank
6. RAG Generation
7. Evaluation

之後才加入：

• Embedding fine-tuning
• Hard negative mining
• Hybrid retrieval
• Graph / domain signal
• Reranker
• Groundedness / Citation / Abstention
• Ablation study

順序刻意這樣排，因為我要能回答：每一層到底貢獻了多少？

第一個要建立的不是 Vector DB，而是 Baseline

企業知識檢索很容易有一個偏見：

Dense Retrieval 一定比 BM25 先進。

但資訊檢索領域的實證並沒有這麼簡單。

BEIR 是常被引用的 zero-shot IR benchmark。它比較 lexical、sparse、dense、late-interaction 與 reranking 等不同架構後，一個非常實用的結論是：BM25 仍然是一個很強、很難忽略的 baseline；reranking 常能提升品質，但會付出更多計算成本。

這件事對企業資料尤其重要。

因為企業文件常常充滿：

• 型號
• 專案代碼
• 縮寫
• 人名 / 部門名
• 專有名詞
• 料號
• 少量但非常關鍵的關鍵字

這些資料不一定符合「語意越相近就越 relevant」的直覺。

所以本系列不會一開始就追求最複雜的方法，而會固定保留幾個 baseline：

BM25
Dense Retrieval
Hybrid Retrieval
Hybrid + Rerank
Fine-tuned Retriever
Fine-tuned + Hybrid + Rerank

沒有 baseline，就不知道後面的複雜度到底值不值得。

沒有 Qrels，就沒有真正的 Retrieval 評測

如果要比較兩個 retrieval pipeline，至少需要知道：

對某一個 Query，哪些文件應該算 relevant？

這就是 relevance judgment，而整理成可供評測使用的形式，通常會形成 qrels。

最簡化的概念可以想成：

Query 001
  ├─ Doc 12 → relevant
  ├─ Doc 37 → highly relevant
  └─ Doc 81 → not relevant

這裡的困難不是檔案格式，而是標註規則。

例如：

• 文件只提到關鍵字，但沒有回答問題，算 relevant 嗎？
• 文件有部分答案，應該是 1 還是 2？
• 兩位標註者不同意怎麼辦？
• Query 寫得太接近原文，會不會讓 BM25 被不公平地放大？
• Candidate pool 是誰產生的？會不會讓某一種 retrieval method 佔便宜？

這些問題如果沒有先定義，最後的數字就很難解釋。

因此在這個系列裡，「資料標註」不是前置雜工，而是 Retrieval Engineering 的核心工作之一。

我會同時量 Retrieval 與 Generation，但不把它們混成一個分數

RAG 的評測至少有兩種不同問題：

Retrieval：有沒有把對的證據找回來？

常見指標包括：

• Hit@K：Top-K 裡有沒有命中 relevant document。
• MRR：第一個 relevant result 出現得有多前面。
• NDCG@K：不只看有沒有命中，也考慮 relevance grade 與排名位置。
• Macro-F1@K：在固定 Top-K 決策下，觀察 precision / recall 的平衡。

NDCG 的直覺很好理解：把高 relevance 的文件排在越前面，分數越高；再用理想排序做正規化，得到 0 到 1 的分數。

Generation：拿到 Context 之後，答案好不好？

這一層則會關心：

• Answer correctness
• Faithfulness / Groundedness
• Citation correctness
• Abstention：沒有證據時，模型會不會硬答

我不希望把兩者混掉。

因為可能出現四種情況：

只有把問題分層，才知道該修哪一段。

Fine-tuning 不會從 LLM 開始，而會先從 Retriever 開始

這個系列會做 Fine-tuning，但重點不是「把 LLM 再訓練一次」。

我更想驗證的是：

Domain-specific terminology 真的讓 embedding retriever 失效時，微調 Retriever 能不能帶來可量化改善？

大致會走：

Query / Positive document
        ↓
Hard Negative Mining
        ↓
Training Set
        ↓
Embedding Fine-tuning
        ↓
固定 Evaluation Set
        ↓
Base vs Fine-tuned

然後不只看平均分數，而會看：

• 哪一類 Query 進步？
• 哪一類 Query 退步？
• 專有名詞是否改善？
• 語意型問題是否改善？
• 是否只是 overfit 到 training query？

如果 Fine-tune 後沒有改善，也會保留結果。

因為工程上的負面結果同樣有價值：它告訴我們「這個成本不值得」。

Rerank 的問題不是「有沒有比較好」，而是「值不值得」

典型 Retrieval Pipeline 可以是：

Query
 ↓
BM25 / Dense / Hybrid
 ↓
Top 50
 ↓
Cross-Encoder / Reranker
 ↓
Top 5
 ↓
RAG

Reranker 常能把真正 relevant 的文件推到更前面，但代價是 latency 與 compute。

所以我會把它當成一個工程 trade-off，而不是魔法元件：

真正要回答的是：

多花的 100～200 ms，換來的 ranking quality 對 downstream RAG 是否真的有價值？

這 30 天最後要得到的不是一個 Chatbot，而是一張可解釋的實驗表

我希望 Day 30 可以回答：

BM25
  ↓ + Dense
Hybrid
  ↓ + Fine-tune
Fine-tuned Hybrid
  ↓ + Rerank
Reranked Retrieval
  ↓ + RAG
Final System

每一步都要有：

• 固定資料
• 固定 Query Set
• 固定 qrels
• 固定指標
• 可重現設定
• latency / quality trade-off
• error analysis

最後不是只展示「最好的模型」，而是做一個 Ablation：

哪些技術真的有效？哪些只是讓架構變複雜？

這也是我對 AI Engineering 的理解：不是把最多技術疊在一起，而是建立一套能證明改動有效與否的方法。

今天的結論

RAG 的核心問題不是「能不能生成答案」，而是：

我們有沒有一套方法，知道 Retrieval 與 Generation 到底哪裡變好了、哪裡變差了？

所以 Day 1 先不裝 Vector DB，也不先換模型。

我先把順序定下來：

資料 → Query → 標註 → Baseline → Fine-tune → Hybrid → Rerank → RAG → Evaluation。

明天第一個要做的，是定義這個系列到底在解哪一種企業知識檢索問題；因為任務定義錯了，後面的所有指標都只是在精準地量錯東西。

下一篇：Day 02｜先定義任務：企業知識檢索到底要回答什麼

參考資料

1. Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
   https://arxiv.org/abs/2005.11401
2. Thakur et al., BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models
   https://arxiv.org/abs/2104.08663
3. scikit-learn, ndcg_score
   https://scikit-learn.org/stable/modules/generated/sklearn.metrics.ndcg_score.html

本系列使用去識別或自建的研究資料與評測流程；文章重點是方法、實驗與可重現性，不公開任何未授權的企業內部文件。